Доклад "Токсичный драйвер".
Токсичный драйвер (со стороны клиента) обычно редкость на проекте.
Стиль его работы: фонтанировать идеями, настаивать, обижаться, забывать договоренности и требовать исполнения сиюминутных желаний.
Поделюсь опытом, как приходится с таким работать, как чувствует себя команда, как планировать и сдавать доработки проекта.
Думаю, в новых условиях, с учетом того, что бизнес-анализ и в целом IT будет всё больше дрейфовать в сторону работы с компаниями с гос. участием, опыт общения с такими менеджерами может пригодится.
В разработке любого it решения не обойтись без фазы бизнес-обследования. Причём обычно Заказчик за него не очень хочет платить, и данная фаза идёт во время пресейловой активности вашей родительской организации. Тем не менее - это очень интересная проектная и аналитическая задача: провести обследование в сжатые сроки и дёшево. У меня иногда получалось и дёшево, и сердито. Секрет успеха я смог оформить в методику, которой хочу с вами поделиться
Одна из частых ситуаций IT-проектах - это недопонимание между IT и бизнесом. Технические специалисты зачастую говорят слишком сложно и порою заумно, что затрудняет коммуникацию и приводит к лишним трудностям при выполнении проектов. В своем докладе я хочу поделиться опытом, а также рассказать о том, как понимать модель данных не IT-специалисту, и о схожести интеграции IT-систем и бара.
Основные вопросы: как объяснить сложное просто на примере моделирования данных и интеграции информационных систем
Уровень слушателей: буду рад видеть всех
Рассказать подробно о том, как правильно и быстро привлечь новых участников проекта с участием более 30 человек
Недавно я поменяла работу и столкнулась с тем, что необходимо быстро и эффективно наладить процесс взаимодействия с продактом, при этом хотелось учесть прошлый опыт, не повторить прошлые ошибки и показать первые победы. Расскажу про:
1) Как коммуницировать и разделять ответствености с продактом. Как проводить встречи с продактом - на первой встрече знакомстве, на встречах 1-1, на встрече обратной связи.
2) Как работать с беклогом. Что делать аналитику, если пустой беклог или слишком перегруженный или слишком быстро меняем приоритеты. Как в этом случае поможет построение CJM и MVP.
3) В каком формате ожидать постановку задач от продакта на спецификацию, чтобы решить проблемы "а зачем мы вообще это делаем", плохого описания и несогласования ТЗ продактом.
На докладе расскажу, как выстраивали порядок и коммуникации при изменениях в общей инфраструктуре.
Инфраструктура - как выглядит у нас и в чем сложность взаимодействия между командами:
Аналитическая инфраструктура состоит из запутанных связей и зависимостей - сервера связаны с серверами, базы с базами, команды с командами. Изменения в одном узле может повлечь изменения в другом.
Какого рода есть изменения - подключение новых источников, изменение имеющихся, удаление устаревших и неактуальных, изменение логики сбора.
Мы сформулировали типы изменений и формат взаимодействия по ним.
Ошибки при взаимодействии. С чем столкнулись и как пришли к чек-листу.
Инструмент или панацея? Что изменилось с введением чек-листа, ограничились только им и нужны ли еще какие-то изменения.
Выводы и рекомендации, опыт команды.
Продолжительность ~40 минут.
На КС обсудим - что случилось с проектированием в разработке ПО и ИС?
Вопросы на КС:
1. Действительно ли так нужны требования, а не проект системы?
2. Кто и как может делать проект системы?
3. Нужны ли индустрии проектировщики?
4. Где взять проектировщиков?
5. Что нужно знать и делать аналитику, чтобы он смог делать проект системы?